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A Fast Algorithm for Liquid Voting on Blockchain* 


SUMMARY _ Blockchain-based voting, including liquid voting, has 
been extensively studied in recent years. However, it remains challenging 
to implement liquid voting on blockchain using Ethereum smart contract. 
The challenge comes from the gas limit, which is that the number of in- 
structions for processing a ballot cannot exceed a certain amount. This 
restricts the application scenario with respect to algorithms whose time 
complexity is linear to the number of voters, i.e., O(n). As the blockchain 
technology can well share and reuse the resources, we study a model of 
liquid voting on blockchain and propose a fast algorithm, named Flash, to 
eliminate the restriction. The key idea behind our algorithm is to shift some 
on-chain process to off-chain. In detail, we first construct a Merkle tree off- 


chain which contains all voters’ properties. Second, we use Merkle proof 


and interval tree to process each ballot with O(log n) on-chain time com- 
plexity. Theoretically, the algorithm can support up to 2! voters with 
respect to the current gas limit on Ethereum. Experimentally, the result 
implies that the consumed gas fee remains at a very low level when the 
number of voters increases. This means our algorithm makes liquid voting 
on blockchain practical even for massive voters. 

key words: liquid voting, blockchain, smart contract, gas limit, Merkle 
tree 


1. Introduction 


Since the inception of Bitcoin, blockchain has shown great 
promises in implementing decentralized cryptocurrencies 
that have attracted significant attentions of academia, indus- 
try and government. Essentially, a blockchain is a decen- 
tralized and immutable public ledger ensured by cryptogra- 
phy and peer-to-peer networking technologies. The ledger 
share the transactions and reuse the technological resources 
across many participants so that any involved record cannot 
be altered retroactively, without the alteration of all subse- 
quent blocks. This allows participants to verify and audit 
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transactions independently and relatively inexpensively [1]. 
The early blockchain implementation, represented by Bit- 
coin, can store simple data formats in the form of money- 
transferring transactions. Later, Ethereum and other emerg- 
ing blockchain projects have enhanced the blockchain by 
involving smart contracts, which are programs running on 
blockchain nodes for storing and operating on-chain data. 
With smart contracts, we can implement various complex 
decentralized applications with strong security and trusti- 
ness guarantee, e.g., insurance, supply chain management, 
the vehicular Internet of Things [2] and copyright protec- 
tion. 

Voting is one of the most popular blockchain applica- 
tions, and plays an important role in many decision-making 
scenarios. Liquid voting (or liquid democracy) is a form 
of delegative democracy [3], which lies between direct and 
representative democracy [4]—[7]. Voters can either vote di- 
rectly or delegate their votes to other participants. Voters 
delegate some others who may further elect other repre- 
sentatives, which forms a delegation graph. Since voters 
may change their delegation by the voting deadline, frequent 
graph operations, like graph traversing, will be executed. 

Graph traversing operations are common and various 
efficient algorithms are available on our traditional comput- 
ing systems. However, it becomes a big challenge for a 
unique limitation called gas limit when we conduct such op- 
erations on blockchain. We take Ethereum as an example. 
Executing a single instruction of smart contracts consumes 
a certain amount of gas fee, which varies from several to 10 
thousand**. Ethereum has a parameter block_gas_limit, 
usually about 10 million, which determines the total gas that 
can be consumed within a block(that is gas limit). The to- 
tal gas fee for invoking a smart contract can not exceed 
block_gas_limit, because the corresponding transaction 
can only be included in one block, which means that the 
number of instructions cannot exceed a certain amount. Oth- 
erwise, the transaction will be reverted. 

Many companies/parties have started practicing appli- 
cations of liquid voting, such as Google Votes [8] and Pirate 
Parties (software: liquid feedback) [9]. However, they are 
centralized solutions that suffer from black-box operations 
and statistical errors. Blockchain is promising in solving 


“According to https://github.com/ethereum/EIPs/blob/master/ 
EIPS/eip-150.md, one storage_modify instruction costs 5000 
gas, and one storage_add instruction costs 20000 gas. 
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these issues, but an efficient blockchain-based implementa- 
tion of liquid voting is still an open challenge. 

The difficulty lies in the self-tally requirement. Self- 
tally means that after all ballots have been cast, anyone can 
compute the result without external help. This is a natural 
requirement for a distributed voting scheme [10]. Naive al- 
gorithms usually compute the result by traversing the del- 
egation graph on-chain, of which the time complexity is 
O(n), where n is the number of voters. Especially, when 
the delegation graph is chain-like, they are undesirable due 
to the gas limit, since application scenarios are limited to 
less than one thousand voters (usually with millions of vot- 
ers required). 

Some discussions try to rise to the challenge by adding 
restrictions to the delegation graph, i.e., set an upper limit to 
the depth of the graph (max_depth). Yet, this would open 
the door to potential griefing attacks. In this case, delega- 
tors can block voters from delegating by delegating a chain 
of depth as max_depth-current_depth'. Other solutions 
abound but are all unreasonable when meet with the gas 
limit. 

In this paper we essentially take the computation pres- 
sure by real-timely updating the status upon each voting 
massage, which gives the icing on the cake for user expe- 
rience by displaying it. We propose an algorithm, named 
Flash, that reduces the on-chain time complexity to O(log n) 
for processing each voting information, which essentially 
solves the on-chain liquid voting problem. The Flash does 
not add any restriction to voters: any voter can delegate ar- 
bitrarily. Its off-chain time complexity is also acceptable, 
which is only O(n). The Flash solves the liquid voting prob- 
lem with the following aspect: 


e At the beginning of a voting, each voter obtains the 
delegation graph by snapshotting the current height of 
Ethereum, then executes an O(n) off-chain initializa- 
tion to get his initialization data. 

e Voters directly vote to a candidate by sending a voting 

message, attached with his initialization data. Upon re- 

ceiving a voting message, the voting contract use the 

Merkle proof to check the correctness of the initializa- 

tion data with O(log n) time complexity. 

After that, the voting contract process the voting mes- 

sage to update the voting status and storage real- 

timely through the interval tree structure which further 
achieves O(log n) time complexity. 


The rest of this paper is organized as follows. In Sect. 2, 
we describe the background technologies and further elicits 
the motivation of this paper. In Sect.3 we discuss the prob- 
lem with an example. In Sect. 4, we present the Flash for the 
liquid voting on blockchain problems. We do some theoret- 
ical analysis and prove some properties of our algorithm in 
Sect. 5. In Sect. 6 we show our experiment results. Finally, 
we conclude the paper in Sect. 7. 


Thttps://forum.aragon.org/t/open-challenges-for-on-chain- 
liquid-democracy/161 
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2. Background and Motivation 
2.1 Voting and Liquid Democracy 


Theories and algorithms of liquid voting have been exten- 
sively studied in recent years. Blum et al.[11] give an 
overview of liquid voting, including concepts, history and 
issues. The latest research progress of liquid voting can be 
found at The Liquid Democracy Journal" . 

Recently, a series of literature studies the implemen- 
tation of blockchain-based voting systems [12], [13], some 
of which also refer to liquid voting but not consider the 
self-tally requirement. The introduction of self-tally can be 
found in [14], which states that the property of self-tally and 
perfect ballot secrecy can not be satisfied simultaneously. 
Thus in this paper the privacy is compromised in favor of re- 
altime self-tallying. Yang et al. [15] introduce a self-tallying 
voting system by Ethereum smart contract, but do not con- 
sider the liquid voting scenario. McCorry et al. [16] also im- 
plement a distributed and self-tally electronic voting scheme 
using the Ethernet blockchain, while the core is to maximize 
the protection of voter privacy. 

There are some applications for liquid voting, as 
Google vote and liquid feedback. The algorithms in them 
work in following ways: Google vote’s algorithm mainly 
bases on the work of Schulze’s [17], which is a m? method 
for electing a winner, where m is the number of candi- 
dates. They also demonstrate that the system can imple- 
ment liquid voting on a social network in a scalable manner 
with a gradual learning curve. The basics of Liquid Feed- 
tional Runoff''** and Schulze method, whose proposes are 
to determine the weights of candidates. Though both al- 
gorithms can be applied to liquid voting, the self-tallying 
requirement and gas limit are not taken into consideration. 


2.2 Merkle Tree and Interval Tree 


Merkle tree [18] is a commonly used data structure for stor- 
ing and verifying data on blockchain. The blockchain stores 
only the root of the Merkle tree (called Merkle root). A leaf 
node together with its correct Merkle proof (also known as 
Merkle path, which is defined as a sequence of nodes in the 
Merkle tree that corresponds to brother of each node on path 
from the leaf node to the root) can recover the root of the 
Merkle tree. Merkle proof is used to concisely proof and 
ensure the validity of a certain data set being inclusive in a 
larger data set without revealing either the complete data set 
or its subset. The length of the Merkle path and the time 
complexity for recovering the Merkle root are all logarith- 
mic to the number of leaf nodes of the Merkle tree. Besides, 
the one-wayness of the hash function guarantees that it is 


*https://liquid-democracy-journal.org/ 
™ https://en.wikipedia.org/wiki/Harmonic_mean 
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hard to construct a correct Merkle proof for any data that 
does not belong to any leaf nodes of the Merkle tree. 

Interval tree is a binary tree that each node holds an 
interval. The interval of any node is uniformly distributed 
to its two child nodes, until the interval becomes a singular, 
to be a leaf node. It supports finding and updating opera- 
tion. For updating operation, usually not every leaf node 
is updated since the updating information may stop at an 
intermediate node, recorded as lazy-tag, and will be exe- 
cuted in subsequent operations. Finding operations need to 
be executed recursively starting from the root, and trigger 
the pass-down operation of all lazy-tags until the leaf node 
is reached. The complexity is O(log n) with respect to inter- 
val tree for both operations. We refer [19], Chapter 10.1 to 
readers for more detail. 


2.3 Motivation 


The security and transparency of the blockchain, combined 
with the freedom and flexibility of liquid democracy, make it 
possible to truly achieve democracy for everyone. However, 
due to the gas limit on Ethereum, the application scenario is 
restricted with respect to algorithms whose time complexity 
is linear to the number of voters, i.e., O(n). Therefore, we 
hope to be able to implement an O(log n) algorithm to elimi- 
nate the restriction, as the total gas fee will never exceed the 
gas limit. There by we can make liquid voting on blockchain 
practical, that without any restriction to voters: no limit to 
the number of voters and voters can delegate arbitrarily. 


3. Problem Description 


In this section, we first define the process of liquid voting on 
blockchain. Second, we formalize the liquid voting prob- 
lem. Finally, we breakdown the problem into subproblems. 

In brief, liquid voting on blockchain can be separated 
into three periods: 


(1) Spare period 


The election organizer allocates voting powers to all voters, 
initializes voters identity if necessary, and deploys the dele- 
gate contract on blockchain. Each voter can arbitrarily del- 
egate or undelegate by sending transactions to the delegate 
contract. In our model, we assume that each voter is al- 
lowed to appoint at most one delegation. During this period, 
no voting is casted, and a voter’s delegation is not allowed 
to change after the spare period. 


(2) Prepare period 


In this period, the election organizer needs to deploy a vot- 
ing contract with the delegation graph from the spare period. 
Notice that the delegation graph could be too large to recon- 
struct on blockchain. We provide more details in Sect. 4. 


(3) Voting period 


After the voting begins, each voter can directly vote to a 
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Fig.1 Delegation tree. We ignore the virtual node with index 0 here. 


candidate by sending a voting message to the voting con- 
tract, with all his delegators’ voting powers also casting to 
the same candidate. It is notable that, although our algo- 
rithm does not allow voters to change their delegations dur- 
ing the voting period, they can accomplish the same purpose 
by casting a direct voting. Changing delegation to a voter 
that has voted is equivalent to casting a direct voting, and 
changing delegation to a voter that has not voted is rare in 
practice. 

We introduce delegation graph to describe voters’ del- 
egation behaviors. A delegation graph G is a direct graph, 
where each node represents a voter, and a direct edge (u, v) 
represents that voter v delegates his voting power to voter u. 
It is intuitive to assume that a delegation graph G contains 
no loop, thus a forest (multiple trees). Additionally, we can 
add a virtual node that is pointed by the root of each con- 
nected branch. So a delegation graph G can be transferred 
to a delegation tree T. If G contains only one connected 
branch, the transfermation can be ingored since it is already 
a delegation tree. Figure 1 shows an example of delegation 
tree for 12 voters, in which voters are indexed by numbers 
1,2,...,”, while candidates are indexed by capital letters 
A, B,C,.... The arrow from the number to the capital let- 
ter represents the voter votes to the candidate with all his 
ballots. 

The liquid voting problem can be described as tally- 
ing all candidates’ ballots with a subset of voters in a del- 
egation tree voting to the candidates. Given that a delega- 
tion tree could contain thousands of nodes, it is difficult, if 
not impossible, to traverse it on-chain due to the gas lim- 
itation. Notice that the involved nodes of each voting is 
quite less than the total number of nodes, we further con- 
vert our goal to self-tallying the ballots of all candidates for 
each voting message. Instead of self-tallying the ballots af- 
ter all votes are casted, our new goal is more applicable for 
the blockchain scenario. We again take Fig. 1 as an exam- 
ple, and further assume each voter’s voting power equals to 
his index for convenience. At the beginning, nobody votes. 
When voter | votes for candidate A (as the first voter), A 
obtains 1 +2+---+ 12 = 78 ballots. After voter 1 votes, 
suppose voter 5 (as the second voter) votes for candidate B. 
Then B obtains 6 + 5 = 11 ballots. A’s ballots decrease by 
11, turning into 67. Further, voter 3 (as the third voter) votes 
for candidate C, then C obtains 3 +4 + 7 + 8 = 22 ballots, 
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Table 1 Expamle of self-tallying the ballots for each voting. 


| inputs | outputs 
1A A78 BO co 
5B A67 Bil CO 
3C A45 Bil C22 


A’s ballots become 45, and B’s ballots don’t change. Table 1 
shows the process. 

It’s obvious that in order to tally the ballots after each 
voting, the key point is to maintain each node’s “lost vot- 
ing power” (the total ballots of his delegators who vote di- 
rectly, initially valued zero). Since a certain delegation tree 
is established, the total voting power (the total ballots the 
voter and all his delegators hold) of each voter is deter- 
mined. When a voter votes, his actual voting power is his 
total voting power minus his lost voting power. Meanwhile, 
some other voters’ lost voting power should be updated after 
he votes. As long as each voter’s lost voting power can be 
updated within O(log n), the liquid voting problem can be 
solved. 

Take Fig. 1 for example, when voter 5 votes, his nearest 
voted parent is voter 1, so all nodes on the path (5) — 4 > 
3 — 2 — (1) are to be updated. When voter 3 votes, nodes 
on the path (3) — 2 — (1) are to be updated. 

So the main two goals of our algorithm are: first, find 
the voter’s nearest voted parent; second, update lost voting 
powers of nodes on the path from the voter to the voter’s 
nearest voted parent. However, to meet both these two goals 
we need to traverse the graph in traditional method, whose 
time complexity is O(n). 


4. Algorithm 


The basic idea of the Flash is to trade off-chain process- 
ing time for on-chain processing time. Specifically, we 1) 
snapshot the delegation graph and construct a Merkle tree in 
which a leaf represents each voter’s information, like voting 
power and delegation; and 2) process the voting message 
on-chain by leveraging both Merkle proof and interval tree, 
which further achieves O(log n) time complexity. Although 
we focus on the time complexity, and the storage space of 
blockchain can be regarded as infinity, the space complexity 
of the Flash is only O(n), because the two main data struc- 
tures are Merkle tree and interval tree, of which the space 
complexity are both O(n). 


4.1 Overview 


We describe the main algorithm in the steps from (A) to (F). 
As mentioned in Sect.3, the delegations are constructed in 
the spare period. 

Step A) At the beginning of the prepare period, all on- 
chain information are snapshotted by the current height of 
the blockchain, mainly, each voter’s delegation and weight. 
Then, each voter involved in the voting locally constructs the 
delegation tree T and gets all voters’ voting powers accord- 
ing to the following two rules. First, for each voter, get his 
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Table 2 Variables used in the algorithm. 

Notation Description 

T The delegation tree, which is generated and 
stored off-chain. 

n Number of nodes, as well as the length of the 
preorder sequence (called preorder index for 
short). 

no Length of the bracket sequence. 

node A type, representing the voters. 

node.weight Node’s voting power, which is given from the 
snapshot. 


node.index 
node.address 


Index of the node in the pre-order sequence. 
The Ethereum address of the node, which is an 
inherent parameter. 


b[] Mapping from a node’s preorder index to the 
node. 

nearestparent[] Mapping from a node’s preorder index to its 
nearest voted parent’s preorder index. 

s[] The score of the bracket sequence (shown in the 
following). 


node. endpoint The maximum preorder index among the 


node’s children (include multi-level). 


node. left The first index where the node appears in the 
bracket sequence. 
node.right The second index where the node appears in the 


bracket sequence. 


node. power Node’s total voting power (including its chil- 


dren’s). 

node.candidate The candidate that the voter votes. 

cf] Recording the ballots of candidates. 

lazy_1[] Lazy-tag of the interval tree with respect to the 
preorder sequence, which also reflects the index 
of the nearest voted parent. 

lazy_2[] Lazy-tag of the interval tree with respect to 


the bracket sequence, which also reflects the 
“score” of the sequence. 


last delegating operation from the snapshot and add the cor- 
responding direct edge to the delegation graph. For all edges 
that are on a cycle, delete the latest edge. Then repeat the 
deletion until the delegation graph has no cycle". After that, 
add an edge from each zero-outdegree node to the virtual 
node, resulting in T. Since the rule is deterministic, all vot- 
ers obtain a same delegation tree. Second, all voters’ voting 
powers can be obtained from the snapshot (node.weight 
in Table 2). There are many off-chain methods in practice to 
distribute voting powers, which is not critical of our paper 
as long as all voters can reach an agreement. 

Step B) After the construction of T, we use T. root to 
denote the root of T (the virtual node). Then, each voter 
locally call Preorder (T.root) (the procedure is shown in 
Algorithm 1) to obtain initialization data. 

Step C) Each voter constructs a Merkle tree ac- 
cording to the initialization data. The information of 
each leaf node is the hash of the node’s initialization 


*All transactions in Ethereum are attached with a timestamp. 
The time order on the blockchain is defined as that if a transaction’s 
block height is larger than another trasaction, the former is later 
than the latter. If two transactions have the same block height, the 
transaction with the larger timestamp is later. The rule of Etherum 
guarantees that the timestamp can not be forged too far from the 
actual time otherwise the transaction is infeasible. 
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Algorithm 1: Procedure of Preorder (root) 


l:nen+l 

2: no —no +1 

3: root.left — no 

4: root.index n 

5: root.power < root.weight 

6: for all node in root’s direct child do 
a Preorder (node) 

8: root.power <— root .power+node. power 
9: end for 

10: root.endpoint <n 

11: no — no+ 1 

12: root.right <— no 


Algorithm 2: Procedure of Vote, upon receiving a 
voting message 


Input: node,voter, data, proof ,node.candidate 


Output: C[] 

1: if not check (RootHash, proof,data) then 

2 return 

3: end if 

4: b[node. index] — node 

5: FAULVP(node. left ,node.left,1,2n,1,0) 

6: FAULVP (node.right,node.right,1,2n,1,0) 

7: t —node.power — s[node. left] + s[node.right] 
8: C[node. candidate] — C[node. candidate] +t 


9: FAUNVP (node. index ,node.index,1,n,1,0) 
10: parent — b[nearestparent [node. index] ] 
11: C[parent.candndate] — C[parent.candndate] -t 
12: FAUNVP (node. index +1,node. endpoint, 1,n,1,node.index) 
13: FAULVP(parent.left,node.left,1,2n,1,) 


data (data=(node. address , node. power ,node. index, 
node.endpoint ,node.left,node.right)). The elec- 
tion organizer deploys a new smart contract (the voting con- 
tract). The Merkle root is hard-coded in the voting contract 
by the election organizer. 

After step C, the prepare period is over and the voting 
period begins. In the following steps, we describe the voting 
contract which processes each direct voting message. 

Step D) When a voter casts a direct voting, he 
sends a voting message which contains (data, proof, 
node.candidate), where data is the initialization data of 
himself and proof is the Merkle path from the leaf node 
(hash(data)) to the Merkle root in the Merkle tree (con- 
structed in step c). 

Step E) Upon receiving a voting message, the voting 
contract first obtains the sender’s Ethereum address to check 
if it matches with node. address in data. If it matches, the 
contract recovers a root according to data and proof. Then 
it checks if the result matches to the Merkle root stored in 
the contract. If matches, the contract begins to process the 
voting message, otherwise returns an “error” response. 

Step F) Algorithm 2 shows the main procedure for pro- 
cessing a voting message, which consists of the following 
instructions: 


e Compute the voter’s lost voting power (line 5 and 
line 6). 
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Algorithm 3: Procedure of FAUNVP(CL, R,1,7,k,v), 
which is to find and update the node’s nearest voted 
parent 


Input: [L,R], which is the interval to be updated 
Input: [/,7r], which is the current interval of the interval tree node 
Input: k, which is the index of interval tree node 
Input: v, which is the value for updating. 
1: if L = land R =r then 
pA if v >lazy_1[k] then 
3 lazy_1[k] = v 
4 end if 
> if L = R then 
6: nearestparent[L] — lazy_1[k] // Recursion ends 
7 end if 
8: else 
9: m e | (l+ r)/2] 
10: if lazy_1[2k] <lazy_1[k] then 


ibs lazy_1[2k] — lazy_1[k] 

12: end if 

13: if lazy_1[2k + 1] <lazy_1[k] then 

14: lazy_1[2k + 1] — lazy_1[k] // pass down the lazy-tag 
15: end if 

16: if L < m then 

17: FAUNVP(L, min{m, R}, L, m, 2k, v) 

18: end if 

19: if R > m then 

20: FAUNVP(max{m + 1, L},R,m+ 1,7r,2k + 1,v) 
21: end if 

22: end if 


e Define ż to be the voter’s total voting power minus lost 
voting power, which represents his actual votes. The 
ballots of the candidate he votes increase by t. 

e Find the voter’s nearest voted parent (line 9), whose 
candidate’s ballots decrease by t. 

e Update other voters’ nearest voted parent (only the 
voter’s children are affected) (line 12). 

e Update the lost voting powers of the nodes on the path 
from the voter to his nearest voted parent (line 13). 


So far, the overall procedure of the Flash is produced. 
The variables used in the algorithm are described in Table 2. 
All variables are global and initially valued 0 unless other- 
wise stated. In the next two subsections we introduce the 
two functions FAUNVP(), FAULVPQ. 


4.2 Find the Nearest Voted Parent 


The function FAUNVP (), of which the procedure is shown in 
Algorithm 3, achieves the goal of finding the voter’s near- 
est voted parent, by implementing the updating operation of 
the interval tree with respect to the preorder sequence. The 
lazy-tag (lazy_1[]) of the interval tree’s leaf node records 
the preorder index of corresponding voter’s nearest voted 
parent. The following observation is sufficient for the cor- 
rectness: 


Observation 1. A node’s preorder index is always smaller 
than its children’s. Preoroder indexes of a node’s children 
are successive to the node’s preorder index. When a voter 
votes, only his children’s nearest voted parents need to be 
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Fig.2 Example of updating lost voting powers in a path. 


updated, which should be at least the voter’s preorder index. 


For a node (voter), indexes from node.index+1 to 
node.endpoint represents the preorder indexes of its chil- 
dren, whose nearest voted parent need to be updated. Since 
they form a successive interval, the interval tree is applica- 
ble. 


4.3 Update the Lost Voting Power 


When a voter votes, the lost voting powers of all the nodes 
on the path from the voter to its nearest voted parented 
should be updated. Take Fig.2 for example, if voter 8 
votes after voter 1 votes, the lost voting powers of the 
nodes on the path 7 — 3 — 2 — 1 should be up- 
dated. However it is not a successive interval in the pre- 
order sequence. We use the bracket sequence to handle 
this problem. A bracket sequence is to record each node 
twice in the pre-order traversal, one as entering and the 
other as exiting, called left bracket and right bracket re- 
spectively. For the tree in Fig.2, the bracket sequence 
is 1,2,3,4,5, 6, 6,5, 4,7, 8,8, 7, 3, 2,9, 10, 10, 11, 11, 12, 12, 
9,1. For a direct path from u to v in a tree, define the 
path’s bracket interval to be indexed from v. leftbracket 
tou. leftbreacket. The following observation shows the 
property of the bracket interval: 


Observation 2. Given a direct path, for any node not lying 
on the path, it either occurs twice or does not occur in the 
path’s bracket interval. For any node lying on the path, it 
occurs exactly once in the path’s bracket interval. Moreover, 
only the node’s first appearance lies in the interval. 


Take Fig.2 as an example, suppose the path from 8 
to 1 is to be updated, its bracket interval is 1,2,3,4,5,6, 
6,5,4,7,8 (index 1-11). Nodes 4,5, 6,11, 12 do not lie on 
the path, so they occur twice or do not occur in the inter- 
val. Nodes 1, 2,3, 7,8 lie in the path, so they occur once in 
the interval. We define an array s[] for recording the so- 
called “score” of the bracket sequence. Given a path where 
the nodes’ lost voting powers need to add some value, we 
add that value to the scores of the path’s bracket interval. 
Then for a node’s lost voting power, we can compute it by 
s[node. left] —s[node.right] The reason is that, when 
we increase the score, only the nodes on the path increase 
their lost voting powers (only s[node.left] increases). 
For a node outside the path, the values of s[node. left] 
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Algorithm 4: Procedure of FAULVP(L, R, l,r,k,v), 
which is to find and update the note’s lost voting 
power 


Input: [L,R], which is the interval to be updated 
Input: [}, r], which is the current interval of the interval tree node 
Input: k, which is the index of interval tree node 
Input: v, which is the value for updating. 
1: if L = l and R =r then 
2: lazy_2[k] — lazy_2[k] +v 
3 if L = R then 
4 s[L] <lazy_2[k] 
5 end if 
6: else 
T: m + (l+ r)/2 
8: lazy-2[2k] — lazy-2[2k] + lazy_2[k] 
9: lazy-2[2k + 1] — lazy-2[2k + 1] + lazy_2[k] 
10: lazy_2[k] < 0 // pass down the lazy-tag 
11: if L < m then 


12: FAULVP (L, min{m, R}, l,m, 2k, v) 

13: end if 

14: if R >m then 

15: FAULVP (max{m + 1, L}, R,m + 1,r,2k + 1,v) 
16: end if 

17: end if 


and s[node.right] either do not change or both increase 
by the same value, thus the lost voting power does not 
change. We construct another interval tree with respect to 
the bracket sequence and maintain the score, recorded in the 
variable lazy_2[] of leaf nodes. The function FAULVP O) 
gives the implementation, of which the procedure is shown 
in Algorithm 4. 


5. Theoretical Analysis 


In this section we prove some properties of the Flash. We 
first analyze our protocol for constructing the delegation 
graph. 


Lemma 1. If a voter’s delegating operation does not gen- 
erate a cycle in the delegation graph (locally checked), the 
corresponding edge will never be deleted. 


Proof. Assume by contradiction that the edge is deleted. By 
definition, there must be a cycle such that the edge is the lat- 
est, which means that the cycle is generated by the appear- 
ance of the edge, contradiction. o 


Lemma 1 means that, if the voter follows the protocol, 
his delegation is garanteed to be retained, which is benefit 
for him. Otherwise if his delegation generates a cycle, it 
may be deleted. (It’s also possible to be retained, if other 
voters further change their delegation so as to remove the 
cycle.) 


Lemma 2. If a voter deviates from our mechanism, by 
building a delegating edge that generates a cycle, this edge 
will not cause other voter’s delegating edge to be refused if 
they follows the protocol. 


Proof. We call the edge built by the dishonest voter A. We 
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prove that, if an edge B is refused with the existence of A, it 
will also be refused without the existence of A. 

Since B is refused, it lies on a cycle which contains A. 
Since A also lies on another cycle, if A is deleted, B still lies 
on a cycle, and should be refused by the protocol. o 


Lemma 2 shows that, even if a voter deviates from the 
protocol, other voters are not influenced. There are also 
sublinear-time algorithms that can judge whether a cycle 
is generated for a incoming delegating edge, which can be 
used in smart contract. However it is more complex and re- 
quires more gas fee for each delegating message. So still 
our protocol is recommended in practice. 


Theorem 1. For each voting message in liquid voting prob- 
lem, the voting status can be updated and displayed within 
O(log n) time complexity. Moreover, our algorithm can be 
deployed on the Ethereum mainnet and overcome the gas 
limitation, for the number of voters more than one million. 


Theorem 1 is our main theorem, which is obvious ac- 
cording to the properties of the tools we used. Here we il- 
lustrate some issues. 1) Processing a voter’s voting message 
does not rely on the initialization data of other voters that 
has not voted, since our algorithm only requires the data 
from the nearest voted parent. 2) The “mapping” structure 
in Solidity (the coding language of Ethereum smart contract) 
satisfies that, the storages are allocated only if they are as- 
signed values. For example, the storage /azy[3] can be al- 
located without the allocation of lazy[1] and lazy[2]. While 
lazy[1] and lazy[2] still can be visit with a default value 0, 
which is just the requirement of our algorithm. 3) The time 
complexity of updating operation in interval tree is O(log n), 
because there are O(log n) levels in a interval tree and at max 
we will have to process 4 nodes in a level. For the part of 
Ethereum, we leave the proof in the experiment section. 


6. Experiment 


We compare our algorithm with traversal algorithm by 
recording the maximum consumed gas fee. We conduct the 
evaluation on Ganache, which is a personal blockchain for 
Ethereum development that can be used to deploy contracts, 
and run tests. Our implementation can be found here’. We 
use the DFS algorithm to implement the traversal algorithm. 
The nodes in the delegation graph represents the users, the 
length of the delegation chain represents the num of users 
when the delegation graph is chain-like. The higher time 
complexity of the voting algorithm makes higher gas fee, 
while the time complexity of the voting is the highest when 
the delegation graph is chain-like. Unlike other networking 
researching that have real data set [20], there is no real data 
set for liquid voting to the best of our knowledge. Therefore, 
Our comparison is from two aspects, 1) gas fee cost by vot- 
ing with the DFS and the Flash, and 2) voting by delegation 
chain root, and by delegation chain leaf, as shown in Fig. 3. 


Thttps://github.com/freeof123/liquid-voting/tree/master/ 
ether-eval/contracts 


1169 
10° -106 
i n z - 
—e— DFS —e— DFS 

g L —E— Flash g L —E— Flash 

7 -Gas Limit EEES a 7 -Gas Limit RODERES 5 
z 6 Z 6 
Os O5 
a a 
O 4 Ò 4 

3 3 

2 2 

1 1 


| | | l l l 
0 1,000 2,000 3,000 0 1,000 2,000 3,000 


Length of delegation chain 
(a) (b) 
Fig.3 Voting by delegation chain (a) root; (b) leaf. 


Length of delegation chain 


Notice that the gas limit is about 6,700,000 according 
to Ganache. Our evaluation shows that: 1) the traversal al- 
gorithm performs better when the delegation chain is short, 
like smaller than 100; 2) our algorithm significantly outper- 
forms the traversal algorithm when the delegation chain is 
long enough; 3) our algorithm can scale up with very lim- 
ited gas increasing, while the traversal algorithm reaches the 
gas limit when the delegation chain grows up to 1,000. 

When voting by a chain leaf by the traversal method, 
the leaf node can be found at the beginning. On the other 
hand, the root node will be found by traversing through all 
the nodes while voting by the chain root. Consequently, 
the gas cost of voting by delegation chain root (Fig. 3 (a)) is 
much higher than by delegation chain leaf (Fig. 3 (b)). Even 
so, the gas fees of both cases grow fast and reach the gas 
limit soon. The height of the chain is the highest among that 
of the normal graphs with the same number of nodes, so the 
cost will be highest when the delegation graph is chain-like. 
The result implies that the consumed gas fee remains at a 
very low level when the number of voters increases. 


7. Conclusion 


In this paper we study the liquid voting problem, where each 
voter can either directly vote to a candidate or delegate his 
voting power to a proxy. In order to make the liquid voting 
on blockchain practical without any restriction to voters, we 
propose a fast algorithm to guarantee that the gas fee of the 
voting transaction on blockchain through Ethereum smart 
contract does not exceed the gas limit. We outline the basic 
idea and overview of our algorithm and then describe the 
two key procedures. Finally, we evaluate our algorithm by 
comparing it with traversal algorithm. Experimental results 
show that our algorithm can be deployed on Ethereum and 
eliminate the restriction, which means it makes liquid voting 
on blockchain practical even for massive voters. 
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